Лекции и практики (1). Курс лекций и материалы для практических занятий
 Скачать 1.01 Mb.
|
Особенности проектирования реляционных БДПроектирование реляционной базы данных проходит в том же порядке, что и проектирование БД других моделей данных, но имеет свои особенности, которые в первую очередь касаются этапа логического проектирования. На этапе логического проектирования реляционной базы данных также необходимо решить следующие задачи: Преобразовать ER-диаграмму в схему БД. Выявить нереализуемые и необычные конструкции данных. Определить все первичные ключи (ПК). Определить типы данных для полей таблиц. Описать все ограничения целостности. Правила преобразования ER-диаграммы в схему БД Правила преобразование ER-диаграммы в схему БД следующие: Каждый тип сущности преобразуется в таблицу БД. В таблицу вносятся все атрибуты, относящиеся к данному типу сущности.    Бинарная связь 1:n (между сущностями разных типов) реализуется с помо- щью внешнего ключа между двумя таблицами (рис. 9.4). Например, ОТДЕЛЫи СОТРУДНИКИ, ГРУППЫи СТУДЕНТЫи т.п. Номер группыв таблице ГРУППЫявляется первичным ключом, а Номер группыв таблице СТУДЕНТЫ– внешним ключом. Это самый часто встречающийся вид связи.
 Рис. 9.4. Преобразование бинарной связи 1:n между сущностями разных типов Примечание: внешний ключ на схеме отражается двунаправленной стрелкой.   Каждая связь со степенью больше двух и связь, имеющая атрибуты, преоб- разуется в таблицу БД (рис. 9.5).
    Рис. 9.5. Преобразование связи с атрибутами Связь 1:1 реализуется в рамках одной таблицы. Исключение из этого прави- ла составляют ситуации, когда связанные сущности существуют независимо друг от друга. Например, связь между сущностями ВОДИТЕЛИи ТРАНПОРТНЫЕ СРЕДСТВАпри условии, что за каждым транспортным средством закреплён один водитель. Эта схема будет включать две таблицы, а связь между ними можно реализовать с помощью уникального (возможно, необязательного) внешнего ключа в той таблице, которая будет считаться подчинённой. Унарная связь 1:n (между сущностями одного типа) реализуется с помощью внешнего ключа, определённого в той же таблице, что и первичный ключ. Например, для отражения в таблице СОТРУДНИКИсвязи руководитьнуж- но добавить в неё поле Руководитель. Это поле будет внешним ключом, ссылающимся на первичный ключ этой же таблицы (рис. 2.9). Такой ключ позволяет отразить иерархию сотрудников, когда у каждого сотрудника мо- жет быть только один непосредственный руководитель, а у директора поле Руководительбудет неопределённым (null).  Бинарная связь типа n:m реализуется с помощью промежуточной таблицы. Например, для сущностей КНИГИи АВТОРЫи связи написатьпромежу- точная таблица будет содержать два внешних ключа: идентификатор книги и идентификатор автора, написавшего эту книгу (рис. 9.6). В эту промежуточ- ную таблицу также вносятся те атрибуты, которые характеризуют эту связь (например, номер автора в списке авторов этой книги).
    Рис. 9.6. Преобразование бинарной связи 1:n между сущностями разных типов Унарная связь n:m реализуется с помощью промежуточной таблицы. Например, для отражения связи ассоциируетсямежду терминами таблицы КЛЮЧЕВЫЕ СЛОВАнужно добавить таблицу АССОЦИАЦИИ, в которой будут два внешних ключа на таблицу КЛЮЧЕВЫЕСЛОВА(рис. 9.7). Рис. 9.7. Преобразование унарной связи кардинальности n:m Выявление нереализуемых связей К нереализуемым относятся связи кардинальностью 1:n или n:m, обяза- тельные в обе стороны. Например, связь заказы–строкизаказов: заказ не может быть пустым, и заказанный товар должен входить в определённый заказ. Т.е. нельзя добавить заказ, пока в нём нет ни одной строки, и нельзя добавить стро- ку в несуществующий заказ. Эта проблема обычно решается так: связь делается необязательной со стороны первичного ключа, а внешний ключ остаётся обяза- тельным. При этом в приложении необходимо предусмотреть правило обработ- ки пустых заказов (например, их удаление). К необычным конструкциям данных можно отнести так называемые вза-имоисключающие связи, когда подчинённая сущность связана с одной из двух родительских сущностей. Например, счёт в банке может принадлежать либо физическому лицу, либо юридическому, и не может принадлежать и тому, и другому либо не принадлежать никому. Такую связь можно реализовать по- разному, например, введением в таблицу счетов двух внешних ключей (номер_физ_лица и номер_юр_лица) и следующего ограничения целостности: (номер_физ_лицаIS NULLANDномер_юр_лицаIS NOT NULL) OR(номер_физ_лицаIS NOTNULLANDномер_юр_лицаIS NULL) Определение первичных ключей В принципе можно создать таблицу и без первичного ключа. Но наличие у каждой таблицы первичного ключа – хороший стиль проектирования БД. Кроме того, если эта таблица является родительской для какой-либо другой таблицы, то определить первичный или уникальный ключ необходимо, чтобы можно было определить внешний ключ в подчинённой таблице. В качестве ПК следует брать тот уникальный атрибут сущности, по которому чаще всего про- исходит обращение к данным. Например, для БД налоговой инспекции это ИНН – индивидуальный номер налогоплательщика, а для БД ФОМС (фонда обязательного медицинского страхования) – номер медицинского полиса. Если у сущности нет уникальных атрибутов, можно рассмотреть уни- кальные комбинации атрибутов. Но первичный ключ не должен быть длинным, т.к. ссылающийся на него внешний ключ будет занимать много памяти. Поэто- му при отсутствии подходящих атрибутов нужно вводить суррогатный первич- ный ключ, который не несёт смысловой нагрузки и служит только для иденти- фикации записей. (Некоторые СУБД позволяют определять значения такого ключа как AUTOINCREMENT, т.е. числовое поле, значение которого начина- ется с 1 и автоматически увеличивается на 1 при добавлении новой записи). Определение типов данных атрибутов Определение типов данных для полей таблиц зависит от требований ПрО. Но можно дать следующие общие рекомендации по выбору типов данных: Для коротких символьных значений и символьных строк фиксированной длины следует выбирать тип CHAR. Например, для поля "единица измере- ния" со значениями 'кг', 'шт.', 'уп.' (char(3)), для поля "пол" (char(1)) и т.п. Для символьных строк переменной длины нужно выбирать тип VARCHAR с указанием максимально возможной длины хранимого значения. Если при добавлении данных длина строки превысит указанное ограничение, система не сможет добавить данные и вернёт сообщение об ошибке. Для числовых атрибутов, не участвующих в сложных расчётах, нужно ис- пользовать основной числовой тип реляционных СУБД – тип NUMBER (или NUMERIC), указывая реально необходимое количество разрядов. Например, для атрибута Номер сотрудникаэто может быть NUMBER(4) (до 10000 че- ловек), а для зарплаты – NUMBER(8, 2) (до 999999.99 рублей). Для числовых атрибутов, которые участвуют в сложных расчётах, следует использовать такие числовые типы, которые хранят данные в машинном (двоичном) представлении. Это ускорит выполнение расчётов. Для числовых атрибутов, имеющих ведущие нули, следует выбирать тип CHAR, а не числовой тип, иначе ведущие нули будут потеряны. Например, для серии и номера паспорта (CHAR(10)). Для хранения дат нужно выбирать тип DATE или его варианты (DATETIME, например). Это позволит использовать арифметику дат и не заботиться о правильности вводимых данных: СУБД сама проверит допустимость даты. Для хранения больших объектов (графических, звуковых и т.п.) следует вы- бирать специальные типы данных, перечень которых зависит от выбранной СУБД. Это могут быть типы LONG, CLOB (character large object), BLOB (bi- nary large object) и другие. Для семантически одинаковых полей разных таблиц нужно выбирать одина- ковые типы данных. Например, ФИО сотрудника и ФИО клиента. Во многих СУБД для упрощения типизации данных можно создать специальные типы данных (с помощью команды create type) и использовать их в качестве ти- пов полей таблиц. Лекция 14. Описание ограничений целостности На этапе логического проектирования необходимо описать все ограниче- ния целостности, обусловленные предметной областью. Типы ограничений це- лостности и ключевые слова SQL, которые позволяют описывать эти ограниче- ния, приведены в разделе 7.1. | ||||||||||||||||||||||