INOMARKALK ru
» » Схема базы данных нарисовать онлайн

Схема базы данных нарисовать онлайн


То есть, объяснять, что такое таблицы, строки, индексы, первичные ключи и ссылочная целостность, не требуется.


Сторим схему базы данных онлайн

Если это не так, боюсь, я вынужден отправить вас к соответствующей литературе. Благо, ее сейчас очень много. Рисуем диаграмму Допустим, требуется спроектировать схему базы данных, в которой хранится информация о музыкальных исполнителях, альбомах и песнях. На начальном этапе, когда у нас еще совсем ничего нет, удобно начать с рисования диаграммы будущей схемы. Можно начать с наброска ручкой на листе бумаги, можно сразу взять специализированный редактор. Их сейчас очень много , все они устроены довольно похожим образом.

При подготовке этой заметки я воспользовался DbSchema.



базы данных онлайн схема нарисовать


Это платная программа, но мне кажется, что она стоит своих денег. Триал у DbSchema, если что, составляет две недели.



данных онлайн нарисовать базы схема


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

Затем полученный скрипт можно скормить используемой вами СУБД: Информацию о том, как установить эту СУБД, вы найдете в этой заметке. Итак, чем же я руководствовался при проектировании схемы?



Схема базы данных нарисовать онлайн видеоматериалы




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



базы онлайн схема данных нарисовать


Грубо говоря, таблица находится в первой нормальной форме 1НФ , если на пересечении любой строки и любого столбца в таблице находится ровно одно значение. Даже если СУБД поддерживает множества или массивы, на пересечении строки и столбца хранится ровно одно значение типа множество или массив. Но в таблице user varchar , phone integer не может быть строки alex - , В 1НФ может быть только две сроки — alex - и alex - Вторая нормальная форма 2НФ означает, что таблица находится в первой нормальной форме, и каждый неключевой атрибут неприводимо зависит от значения первичного ключа.

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

Таблица находится в третьей нормальной форме, если она находится в 2НФ и ни один неключевой атрибут не находится в транзитивной функциональной зависимости от первичного ключа.

Очевидно, что она находится в 2НФ.


Создание базы данных

Но телефон отдела находится в транзитивной функциональной зависимости от имени сотрудника, так как сотрудник однозначно задает отдел, а отдел однозначно задает телефон отдела. Для приведения таблицы в 3НФ нужно разбить ее на две таблицы — employee - department и departmnet - phone. Легко видеть, что нормализация уменьшает избыточность базы данных и препятствует внесению случайных ошибок. Например, если оставить таблицу из последнего примера в 2НФ, то можно по ошибке прописать одному и тому же отделу разные телефоны.

Или рассмотрим компанию с пятью отделами и сотрудниками. Если у отдела поменялся номер телефона, то для его обновления в базе данных в случае 2НФ потребуется просканировать строк, а в случае с 3НФ только пять. Как я уже отмечал, есть и более строгие нормальные формы , но на практике обычно используются только первые три. Отношение один ко многим На приведенной диаграмме можно заметить, что каждый исполнитель относится к какой-то стране, и каждый альбом принадлежит какому-то исполнителю.

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

Для моделирования такого типа отношения в каждом альбоме указывается id исполнителя, и в каждом исполнителе указывается id страны. Понятное дело, мы не просто пишем туда какую-то циферку, а возлагаем ответственность по контролю ссылочной целостности на нашу СУБД: Я не вижу причин не проверять ссылочную целостность, если только вы не пишите супер-пупер высоконагруженный проект, у которого исполнители хранятся на одном сервере, а альбомы — на другом.

В противном случае вас ждет много часов увлекательной отладки вашего приложения в ночь с субботы на воскресенье, потому что как-то так получилось, что кто-то создал альбом с несуществующим исполнителем. Это сравнительно небольшие таблицы, состоящие из двух столбцов — id и названия. Если, например, мы захотим переименовать страну Russia в Russian Federation, нам придется поменять всего лишь одну строчку в таблице countries, а не править кучу строк в таблице artists, что может привести к очень большому количеству дисковых операций.

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

Здесь мы имеем место с типичным отношением многие ко многим. Оно моделируется путем введения дополнительной таблицы.

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


Коротко о себе

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

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

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

В окне Добавление таблиц необходимо выделить имена таблиц и нажать кнопку Добавить, при этом в окне "Схема данных" появятся все tables рис. После этого необходимо закрыть окно диалога. Далее необходимо установить связи между табл. Для этого в окне Схема данных необходимо отбуксировать переместить поле КодГруппы из таблицы Группы студентов на соответствующее поле tables Студенты, в результате этой операции появится окно "Изменение связей" рис.


Год выпуска: 2001
Поддерживаемые ОС: Windows XP, 8, 8.1,7, OSX
Локализация: Русский Английский
Вес : 28.94 Мегабайт




Блок комментариев

Ваше имя:


Электронная почта:




  • © 2010-2017
    inomarkalk.ru
    Напишите нам | RSS фид | Карта сайта