Базы данных

     Формируемые системой отчеты позволяют быстро проверить   корректность спроектированной базы данных.

     ERwin - это не что гораздо большее, чем просто инструмент для «рисования"; он автоматизирует процесс проектирования.  Например, ERwin  предусматривает возможность создания каталога наиболее часто  используемых атрибутов, что обеспечивает согласованность имен и   описаний  по  всему  проекту.

     Представления БД поддерживаются как интегрированные компоненты  модели, что позволяет автоматически отображать в их описаниях  изменения,  внесенные в базовые таблицы. Автоматический перенос ключей  обеспечивает ссылочную целостность базы данных. Кроме того, ERwin  позволяет работать с большими моделями общекорпоративного масштаба,  разбивая их на фрагменты и  легко управляемые подмножества, предоставляя  отдельным специалистам возможность сосредоточить свои усилия в  определенной  области.  Возможность  сохранения отображений  позволяет  хранить множество представлений одной предметной области,  ориентированных на различную целевую аудиторию. Созданные  с помощью  ERwin модели данных можно редактировать, просматривать и распечатывать различными способами. В состав ERwin входит RPTwin - простая в   использовании, оснащенная графическим интерфейсом утилита для формирования отчетов и встроенное средство для просмотра с  настраиваемыми режимами, которые обеспечивают полный контроль над отображением  содержимого отчетов. Кроме этого, уникальный  интерфейс,  построенный  на  использовании шаблонов,  позволяет   реализовать   единые   стандарты   проектирования   и отображать настройки для всех моделей.

            ERwin - не только лучший инструмент для проектирования баз данных, но и средство для их быстрого создания.  ERwin оптимизирует   модель в соответствии с физическими характеристиками целевой базы данных. В отличие от других инструментальных средств, ERwin   автоматически поддерживает согласованность логической и физической схем и осуществляет преобразование логических конструкций, таких как  отношения многие-ко-многим, в их реализацию на физическом уровне.   ERwin устанавливает естественную динамическую связь между моделью и базой данных, что позволяет реализовать как прямой, так и обратный инжиниринг. Используя эту связь, Erwin автоматически генерирует   таблицы, представления, индексы, правила поддержания целостности ссылок (первичных и внешних  ключей), устанавливает значения по умолчанию и ограничения для  доменов/столбцов. В состав Erwin включен  целый  ряд  оптимизированных шаблонов триггеров, обеспечивающих целостность  ссылок,  и  мощный  макроязык, который  позволяет  создавать собственные  триггеры  и  хранимые процедуры. Таким образом могут быть автоматически   сформированы тысячи строк кода, что обеспечивает непревзойденную продуктивность разработки на основе моделей.

     База  данных  может быть спроектирована и создана без написания отдельных  SQL-предложений типа CREATE TABLE или INDEX. Поскольку физическая  схема формируется на  основе описательной  логической  модели,  приложение  будет  сразу   же   полностью документировано.  ERwin позволяет также проводить обратный инжиниринг существующих баз данных путем построения модели непосредственно на основе ее таблиц. Таким образом можно получить четкое представление о  структуре  и содержании существующего приложения. ERwin поддерживает все   наиболее популярные реляционные СУБД, включая Oracle, Microsoft SQL Server, Sybase, DB2 и Informix. Одна и та же модель может быть  использована  для создания нескольких баз данных или для переноса приложения с платформы одной СУБД  на другую.

           ERwin интегрирует проектирование базы данных в процесс разработки приложения. Благодаря возможностям взаимодействия с  популярными средствами разработки  для  архитектуры  клиент/сервер  и   Web, ERwin поддерживает соответствие между серверной базой данных  и  формами в клиентской части, позволяя ускорить создание высококачественных приложений. 

3. Построение концептуальной модели предметной области

     Концептуальная модель (информационно-логическая модель) — ориентированная на человека и не зависимая от типа СУБД модель предметной области, определяющая совокупности информационных объектов, их атрибутов и отношений между объектами, динамику изменений предметной области, а также характер информационных потребностей пользователей. Концептуальная модель предметной области может быть описана моделью "сущность—связь" (моделью Чена), в основе которой лежит деление реального мира на отдельные различимые сущности, находящиеся в определенных связях друг с другом, причем обе категории — сущность и связь полагаются первичными, неопределенными понятиями.

     Цель - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому концептуальную модель данных пытаются строить по аналогии с естественным языком ( последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка).

     Требования, предъявляемые к концептуальной модели:

1. Адекватное, отображение предметной области;
2. Недопущение неоднозначной трактовки модели;
3. Четкое определение моделируемой предметной области;
4. Легкая расширяемость, обеспечивающая ввод новых данных без изменения ранее определенных, то же относят и к удалению данных;
5. Возможность композиции и декомпозиции модели в связи с большой размерностью реальных инфологических моделей;
6. Легкое восприятие различными категориями пользователей. Желательно, чтобы концептуальную модель строил (или хотя бы участвовал в ее создании) специалист, работающий в данной предметной области, а не только проектировщик систем машинной обработки данных;
7. Применимость языка спецификаций модели как при ручном, так и при автоматизированном проектировании информационных систем.

На Рисунке 1.изображены связи между сущностями БД «Фирма-посредник».

Рисунок 1.- Связи между сущностями 

Таким образом, концептуальная модель является, по существу, моделью предметной области. 
 
 
 
 
 
 
 
 
 
 
 

4. Проектирование логической структуры базы данных

     Основной  целью этапа создания логической модели базы данных является преобразование информационной модели предметной области базы данных в логическую модель реляционной базы данных. Создание логической модели базы данных предполагает решение следующих основных задач и выполнения операций в рамках таких задач:

1. нормализация сущностей предметной области:
2. получить список атрибутов сущности;
3. определить функциональные зависимости (ФЗ) в сущности;
4. определить детерминанты сущности;
5. определить возможные ключи отношения, в частности, рассмотрев уникальный идентификатор сущности.
6. выполнить нормализацию сущности (преобразовать сущность в отношение);
7. для полученного отношения назначить первичные ключи;
8. сформировать список кандидатов на внешние ключи, если необходимо;
9. сформировать бизнес-правила поддержки целостности сущности, если необходимо;
10. нормализация отношений логической модели базы данных:
11. определить степень связи сущностей;
12. определить класс принадлежности сущности к связи;
13. нормализовать отношение (разрешить связи);
14. назначить первичные ключи связывающих отношений, исходя из уникального идентификатора связи и процедуры миграции ключей при нормализации;
15. определить атрибуты связывающих отношений, если необходимо;
16. сформировать бизнес-правила поддержки целостности связей;
17. проверка правильности логической модели реляционной базы данных:
18. проверка отношений на соответствие нормальной форме Бойса-Кодда;
19. проверка отношений на свойства соединения без потерь и сохранения функциональных зависимостей;
20. предотвращение потери данных путем миграции первичных ключей отношения и назначения внешних ключей;
21. проверка на отсутствие незамкнутых связей;
22. проверка на отсутствие одиночных отношений;
23. формулировка части исходных данных для решения задачи управления ссылочной целостностью;
24. документирование логической модели реляционной базы данных;
25. принятие решения о реализуемости построенной логической модели реляционной базы данных;
26. принятие решения о разработке физической модели реляционной базы данных.

      Результатом проектирования логической модели базы данных является нормализованная схема  отношений базы данных. Отмечу, что в ходе выполнения этапа создания логической модели базы данных могут быть созданы новые объекты базы данных, не предусмотренные в информационной модели предметной области, например, связывающая сущность при нормализации отношения со степенью связи "многие-ко-многим".  
 
 
 
 
 
 
 
 
 
 
 

Рисунок 2. - Логическая структура базы данных «Фирма-посредник»

     На  Рисунке 2. изображена логическая структура базы данных «Фирма-посредник», выполненная в ER-Wine. На ней отображены сущности, их атрибуты и связи между сущностями. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

5. Выявление перечня ограничений целостности

     Целостность базы данных - соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется ограничением целостности (integrity constraint).

     Задача  аналитика и проектировщика базы данных — более полно выявить все имеющиеся ограничения целостности и задать их в базе данных.

     Целостность БД не гарантирует достоверности  содержащейся в ней информации, но обеспечивает, по крайней мере, правдоподобность этой информации, отвергая заведомо невероятные, невозможные значения. Таким образом, не следует путать целостность БД с достоверностью БД. Достоверность (или истинность) есть соответствие фактов, хранящихся в базе данных, реальному миру. Очевидно, что для определения достоверности БД требуется обладание полными знаниями как о содержимом БД, так и о реальном мире. Для определения целостности БД требуется лишь обладание знаниями о содержимом БД и о заданных для неё правилах. Поэтому СУБД может (и должна) контролировать целостность БД, но принципиально не в состоянии контролировать достоверность БД. Контроль достоверности БД может быть возложен только на человека, да и то в ограниченных масштабах, поскольку в ряде случаев люди тоже не обладают полнотой знаний о реальном мире.

     Обеспечение целостности БД - важнейшая задача при создании БД, поскольку обеспечение адекватности базы данных отображаемой предметной области является одним из основных требований, предъявляемых к БД.

     Существует 3 вида ограничений целостности:

1. Целостность по сущностям;
2. Целостность по ссылкам;
3. Целостность, определяемая пользователем.

     Объекту, или сущности реального мира, в БД соответствуют кортежи отношения. Любой кортеж должен быть отличим от любого другого кортежа по составным значениям заранее определенного множества атрибутов, т.е. любое отношение должно обладать первичным ключом.

     Первичный ключ представляет собой один из примеров уникальных индексов и применяется для уникальной идентификации записей таблицы. Никакие из двух записей таблицы не могут иметь одинаковых значений первичного ключа. Первичный ключ обычно сокращенно обозначают как PK (primary key).

     В реляционных базах данных практически всегда разные таблицы логически связаны друг с другом. Первичные ключи как раз используются для однозначной организации такой связи.

     По  способу задания первичных ключей различают логические (естественные) и суррогатные (искусственные).

     Для логического задания первичного ключа нужно выбрать в базе данных то, что естественным образом  определяет запись. Примером такого ключа  является номер паспорта в базе данных о паспортных данных жителей.

     Если  подходящих примеров для естественного задания первичного ключа не находится, пользуются суррогатным ключом. Суррогатный ключ представляет собой дополнительное поле в базе данных, предназначенное для обеспечения записей первичным ключом.

     В БД «Фирма-посредник» я использовала искусственные первичные ключи, так как такой способ их назначения более простой, понятный и не создающий путаницы.

     Для сущности «Товар» первичным ключом стало поле «Код товара», «Поставщики» - «Код поставщика», «Клиенты» - «Код клиента», «Продажа» - «Код продажи», «Поставка» - «Код поставки», «Менеджер поставки» - «Код менеджера поставки», «Менеджеры продажи» - «Код менеджера продажи».

     Требование  целостности по  сущности означает, что первичный ключ должен полностью  идентифицировать каждую сущность, а  поэтому в составе любого значения первичного ключа не допускается наличие неопределенного значения Null.