бд

Под технологической сетью проектирования (ТСП) будем понимать взаимосвязанную по входам и выходам последовательность технологических операций проектирования,

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

Рис.2.2. Графическаяинтерпретацияфрагмента ТСП Здесьпредставленытехнологическиеоперации Т1 с преобразователем П1 и Т2 с преобразователем П2.

Компоненты V ...V являютсявходнымидлятехнологическойоперации Т1, 11 1n

причемнавыполнениеэтойоперациитребуетсяресурсы R1 и средствапроектирования

S1.

Компоненты W ...W являютсявыходнымипоотношения к технологическойоперации Т1, 1 m

в тожевремянекоторыесоставляющиекомпоненты

W ...W являютсявходнымипоотношению к технологическойоперации Т2, 11 1m

следовательноониявляютсяпромежуточными.Длятехнологическойоперации Т2

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

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

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

22. Преимущества семантического моделирования по сравнению с алгоритмом нормализации отношений. Модель Entity-Relationship (ER-модель) как инструмент семантического моделирования. Основные понятия ER-модели.Пример ER-модели.

Семантическое моделирование представляет собой моделирование структуры данных, опираясь на смысл этих данных. В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship).

Основными понятиями ER-модели являются сущность, связь и атрибут. Сущность – это реальный или представляемый объект, информация о котором должна сохраняться и быть доступной. Связь – это графически изображаемая ассоциация, устанавливаемая между двумя типами сущностей. Атрибутом сущности является любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности.https://vk.com/photo172161398_456244895

23. Основные понятия модели ER-модели. Понятие и типы сущностей.Обозначение сущностей в различных нотациях.Привести примеры сущностей.Понятие и типы связей. Обозначение связей в различных нотациях. Привести примеры связей.

Выделяют три вида сущностей: стержневая, ассоциативная (ассоциация) и характеристическая(характеристика).

Стержневая сущность

Стержневая (сильная) сущность – не зависящая от других сущность. Стержневая сущность не может быть ассоциацией, характеристикой или обозначением (см. ниже).

Иногда используют также понятие "слабая сущность". Это сущность, которая не может быть однозначно идентифицирована с помощью собственных атрибутов, а только через связь с другой сущностью. Пусть, например, номер сотрудника является уникальным только в пределах отдела, т.е. в разных отделах могут быть сотрудники с одинаковыми номерами. Уникальной в данном случае будет комбинация "номер сотрудника, номер отдела". Сущность "Сотрудник" является слабой.

Ассоциативная сущность (или ассоциация) выражает собой связь «многие ко многим»

между двумя сущностями. Является вполне самостоятельной сущностью. Например, между сущностями ТОВАР и КЛИЕНТ существует ассоциативная связь, выражаемая ассоциативной сущностью ЗАКАЗАННЫЙ _ТОВАР.

Характеристика

Характеристическую сущность еще называют слабой сущностью. Она связана с более сильной сущностью связями «один ко многим» и «один к одному». Характеристическая сущность описывает или уточняет другую сущность. Она полностью зависит от нее и исчезает с исчезновением последней. Например, сущность ЗАРПЛАТА является характеристикой конкретных работников предприятия и не может в таком контексте существовать самостоятельно – при удалении экземпляра сущности РАБОТНИК должны быть удалены и экземпляры сущности ЗАРПЛАТА, связанные с удаляемым работником.

Связи «один ко многим» Связи «многие ко многим» Связи «один к одному» Связи «один ко многим»

Связь «один ко многим» самая распространенная. В этом типе связей у строки таблицы А может быть несколько совпадающих строк таблицы Б, но каждой строке таблицы Б может соответствовать только одна строка из А. Например, между таблицами publishers и titles установлена связь «один ко многим»: каждый издатель публикует много книг, но каждая книга публикуется только у одного издателя. Используйте связь «один ко многим», если только у одного из связанных столбцов есть ограничение первичного ключа или уникальности.

Столбец, являющийся первичным ключом в связи «один ко многим», отмечается символом ключа. Столбец, являющийся внешним ключом в связи «один ко многим», отмечается символом бесконечности.

Связи «многие ко многим»

Всвязи «многие ко многим» строке таблицы А может сопоставляться несколько строк таблицы Б, и наоборот. Такие связи создаются определением третьей таблицы, которая называется таблицей соединения, чей первичный ключ состоит из внешних ключей А и Б. Например, между таблицами authors и titles связь «многие ко многим» определена через связи «один ко многим» каждой из этих таблиц с таблицей titleauthors. Первичный ключ таблицы titleauthors представляет собой сочетание столбца au_id (первичный ключ таблицы authors) и столбца title_id (первичный ключ таблицы titles).

Связи «один к одному»

Всвязи «многие к одному» строке таблицы А может сопоставляться только одна строка таблицы Б, и наоборот. Связь «один к одному» создается, если для обоих связанных ключей определены ограничения первичного ключа или уникальности. Этот тип связи обычно не используется, так как большую часть связанных таким образом данных можно хранить в одной таблице. Связь «один к одному» можно использовать для:

Разделения таблицы со многими столбцами.

Изоляции части таблицы из соображений безопасности.

Хранения кратковременных данных, которые можно легко удалить вместе со всей

таблицей.

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

символом ключа. Столбец, являющийся внешним ключом, также отмечается символом ключа.

24. Нотации ER-моделирования: понятие, виды, отличительные особенности, примеры отображения элементов в различных нотациях.

1.1.Нотация Чена

Сущность прямоугольник, в который вписано имя.

В одинарной рамке – независимая сущность, в двойной – зависимая сущность. Связь изображается в виде ромба с именем. Идентифицирующая связь – ромб с двойной рамкой.

Атрибут изображается в виде овала с именем.

Атрибут-первичный_ключ – двойное подчеркивание имени.

Атрибут-внешний ключ – одинарное подчеркивание имени.

1.2.Нотация Мартина

Независимая сущность, зависимая сущность – как у Чена.

Атрибуты вписываются внутрь сущности под именем.

Связь между сущностями – сплошная линия.

Множественная связь – сплошная линия с разветвлением на конце.

К одному – сплошная линия, на конце крест.

Модальная связь «может» - как ветвление, но с овалом на линии перед ветвлением.

Связи именуются (прямо на линиях).

1.3.IDEF 1x

Независимая сущность – как у Чена. Зависимая сущность – прямоугольник со скругленными краями.

Идентифицирующая связь – сплошная линия.

Неидентифицирующая связь – пунктирная линия.

Линия – связь один-к-одному.

Линия с жирной точкой на конце – один-ко-многим.

Сбуквой z на конце – один-к-перечислимому-множеству

Сцифрой – один-к-N

Отношение категоризации – одна сущность разделяется на подкатегории. Категоризация бывает

а) полная

б) неполная

1.4.Нотация Баркера

Повторяет нотацию Мартина, но ключевые атрибуты в данном случае выделяются знаком #.

25. Цель нормализации. Нормальные формы ER-схем.

Нормализация позволяет обезопасить базу данных от логических и структурных проблем, называемых аномалиями данных. К примеру, когда существует несколько одинаковых записей в таблице, существует риск нарушения целостности данных при обновлении таблицы. Таблица, прошедшая нормализацию, менее подвержена таким проблемам, т.к. ее структура предполагает определение связей между данными, что исключает необходимость в существовании записей с повторяющейся информацией. В первой нормальной форме ER-схемы устраняются повторяющиеся атрибуты или группы атрибутов, т.е. производится выявление неявных сущностей, "замаскированных" под атрибуты.

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

В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности.

26. Алгоритм преобразования ER-модели в схему реляционной БД.

Алгоритм перехода от ER-модели к реляционной модели данных обычно сводится к следующим шагам:

1.Каждой сущности ставится в соответствие отношение РМД. Имена отношений могут быть ограничены требованиями конкретной СУБД, они ограничены по длине и не должны содержать пробелов и некоторых специальных символов.

2.Каждый атрибут сущности становится атрибутом соответствующего отношения, на их имена также могут накладываться некоторые ограничения . Для каждого атрибута задается конкретный допустимый в СУБД тип данных и обязательность или необязательность данного атрибута.

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

4.В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов первичного ключа главной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом.

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

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

27. CASE-средства проектирования БД: назначение, базовые функциональные возможности, примеры современных CASE-средств.

CASE-средства – это автоматизированные средства, основанные на CASE-технологиях, позволяющие автоматизировать отдельные этапы жизненного цикла программного обеспечения. Все современные CASE-средства могут быть классифицированы по типам и категориям.

Классификация по типам включает следующие основные CASE-средства:

1.Средства анализа, предназначенные для построения и анализа моделей предметной области (Bpwin, Design/IDEF);

2.Средства анализа и проектирования, предназначенные для создания проектных спецификаций (CASE.Аналитик, Vantage Team Builder, Designer/2000, Silverrun, PRO-IV);

3.Средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных для наиболее распространенных СУБД

(Silverrun, Vantage Team Builder, Designer/2000, ERwin, S-Designor);

4.Средства разработки приложений и генераторы кодов (Vantage Team Builder, Silverrun, PRO-IV);

5.Средства реинжениринга, обеспечивающие анализ программных кодов, схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем баз данных входят в состав: (Silverrun, Vantage Team Builder, Designer/2000, Erwin, S-Designor).

Для анализа программных кодов используются такие средства, как Rational Rose и Object Team.

28. Состав работ, выполняемых на стадии логического проектирования БД.

Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.

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

На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.

1.

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

2.

Определение набора таблиц исходя из модели и их документирование. Для каждой сущности модели

создается таблица. Имя сущности – имя таблицы. Осуществляется формирование структуры таблиц на основании изложенных в параграфе 1.4 правил. Устанавливаются связи между таблицами посредством механизма первичных и внешних ключей. Структуры таблиц и установленные связи между ними документируются.

3.

Нормализация таблиц. Для правильного выполнения нормализации проектировщик должен глубоко изучить семантику и особенности использования данных. На этом шаге он проверяет

корректность структуры таблиц, созданных на предыдущем шаге.

4.

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

пользователями. Эти требования представляют собой ограничения,

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

5.

Определение требований поддержки целостности данных и их документирование.

6.

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