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

Выбор системы управления и программных средств БД

От выбора системы управления БД зависит практическая реализация информационной системы. Наиболее значимыми критериями в процессе выбора становятся параметры:

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

Ошибки в выборе СУБД практически наверняка впоследствии спровоцируют необходимость корректировать концептуальную и логическую модели.

Запросы к базе данных и отчёты

Запросы:

• доступность выбираемого в селекторе препарата в выбираемой в селекторе аптеке на данный момент времени;
• группы препаратов, которых нет в выбираемой в селекторе аптеке на данный момент времени;
• аптеки, в которых есть дефицит любого препарата по введённой дате;
• покупки препаратов, которые есть на витринах аптек по введённой дате с указанием препаратов и аптек;
• клиенты, совершившие покупки в выбранной в селекторе аптеке по введённой дате.

Отчёты:

• о количестве покупок со списком аптек по введённой дате с указанием сумм;
• о продажах выбранного препарата во всех аптеках по введённой дате;
• о проданных препаратах стоимостью более 150 рублей по введённой дате;
• о препаратах, которые есть на витрине во всех аптеках;
• о клиентах, зарегистрированных в определённый интервал времени.

Поделиться с друзьями

Реляционные базы данных и язык SQL

Анализ предметной области

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

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

В каждой из аптек регистрируется покупка каждой единицы препарата и все покупки, совершённые одним клиентом в одной аптеки в один момент времени, прикрепляются к корзине покупок.

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

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

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

Типы отношений

В каждом отношении может присутствовать две и более сущностей, и в зависимости от количества сущностей отношения между ними могут описываться как бинарные (binary), тернарные (ternary), кватернарные (quaternary) и т.д. В реальной жизни чаще всего встречаются отношения бинарного типа, поэтому давайте остановимся на них более подробно.

Мощность (cardinality), или количество элементов, отношения показывает, сколько экземпляров одной сущности может соотноситься с экземпляром другой сущности. Тот факт, что бинарное отношение отражает взаимоотношения между двумя сущностями, вовсе не означает, что между ними всегда существует отношение типа “один к одному”.

Отношения между сущностями могут представлять собой и отношения типа “один к од- ному”, и “один ко многим”, и “многие ко многим” или отношения еще какого-то другого типа. Чаще всего встречаются отношения следующих типов (при условии наличия двух сущностей, A и B).

• Один ко многим. В таких отношениях каждый экземпляр сущности A может иметь отношение с несколькими членами другой сущности B. Например, сущность под названием Клиент может брать много книг из библиотеки, но каждая книга за раз может выдаваться только одному единственному Клиенту. Соответственно получается, что между сущностями Клиент и Книга должно существовать отношение типа “один ко многим”. Разумеется, такое отношение может и не существовать при наличии Клиента, который еще не брал никакой Книги. То есть фактически отношение должно гласить следующее: “один Клиент может брать ноль, одну или более Книг”.
• Один к одному. В таких отношениях только один экземпляр любой из сущностей может иметь отношение с экземпляром другой сущности. Например, у каждого человека может быть только один действительный номер карточки социального страхования (Social Security Number — SSN), а каждый номер карточки социального страхования может ссылаться только на одного человека.
• Многие ко многим. В таких отношениях каждый экземпляр сущности A может иметь отношение с одним и более экземплярами сущности B, а каждый экземпляр сущности B — с одним и более экземплярами сущности A. В качестве примера возьмем сущность под названием Кинозвезда и сущность под названием Кинофильм. Каждая кинозвезда может сниматься в нескольких Кинофильмах, и в каждом Кинофильме может принимать участие несколько Кинозвезд. В реальной жизни отношения типа “многие ко многим” обычно разбиваются на более простые отношения типа “один ко многим”, которые, как сложилось, являются наиболее распространенной формой отношений между сущностями.

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

Литература

• Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: «Вильямс», 2006. — 1328 с. — ISBN 0-321-19784-4.
• Когаловский М.Р. Перспективные технологии информационных систем. — М.: ДМК Пресс; Компания АйТи, 2003. — 288 с. — ISBN 5-279-02276-4.
• Когаловский М.Р. Энциклопедия технологий баз данных. — М.: Финансы и статистика, 2002. — 800 с. — ISBN 5-279-02276-4.
• Кузнецов С. Д. Основы баз данных. — 2-е изд. — М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с. — ISBN 978-5-94774-736-2.
• Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. — 3-е изд. — М.: «Вильямс», 2003. — 1436 с. — ISBN 0-201-70857-4.
• Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. — М.: «Вильямс», 2003. — 1088 с. — ISBN 5-8459-0384-X.

Современная база данных

Реляционные отношения лежат в основе любой информационной модели. Решения от Oracle эквивалентны MySQL по сути, но они кардинально различны по многим аспектам. Проектирование баз данных — это также вопросы безопасности, объема информации и меры ответственности за достоверность данных, но они вторичны в контексте вопроса проектирования эффективной, надежной и удобной в пользовании базы данных.

Таблицы Excel — ничем не отличаются от Oracle и MySQL в контексте прямоугольных (реляционных) конструкций: столбцы и строки = одна ячейка на пересечении имени столбца (поля) и индекса выборки (строка). Если не учитывать меру и объем ручного труда, то, благодаря развитым средствам объединения ячеек по вертикали и горизонтали, Excel опережает даже Oracle!

Excel, по его основной идее, никогда «не светит» динамика, функционал Oracle, и перенести что-то с одного листа на другой «по остаткам» он не может. Здесь Oracle перспективнее, но ее соображения по вопросам миграции больших объемов информации и объединению формализованных позиций из различных источников оставляют желать лучшего. Здесь MySQL перспективнее: она не ставит перед собой глобальных задач, но свою работу исполняет отменно.

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

Современная БД — это таблицы, строки, столбцы и индексы, окруженные полным функционалом, развитыми дополнительными средствами, учитывающими множественные операции, большие нагрузки и огромные объемы.

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

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

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

Диодный мост – что это такое?

Как мы знаем, в наших розетках протекает переменный электрический ток с напряжением в 220 вольт. Но как быть если нам нужно запитать низковольтный приемник, которому требуется постоянный ток? Если с напряжением все понятно – нам поможет трансформатор, то как сделать из переменного тока постоянный – вопрос.

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

2.1. Этапы проектирования бд

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

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

Проектирование
базы данных состоит в построении
комплекса взаимосвязанных данных. На
рисунке 1 условно отображены этапы
процесса проектирования базы данных.

Рис.1 — Этапы процесса
проектирования базы данных

Процесс
проектирования Базы данных начинается
с постановки за­дачи и выявления
объектов, процессов или сущностей
предметной об­ласти. Например, объектами
могут быть Институт, Сотрудники. Для
каждого из объектов выбирается набор
характеризующих его свойств (полей,
реквизитов). Для института – наименование,
адрес, расчетный счет и пр., для сотрудника
– фамилия, имя, отчество, адрес, паспортные
данные, пр. Затем в про­цессе анализа
определяется информационная потреб­ность
каждой за­дачи, которую составляют
входные и результатные до­кументы, и
опре­деляется периодичность решения
задач.

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

Концептуальное
проектирование
– сбор, анализ и редактирование требований
к данным. Для этого осуществляются
следующие мероприя­тия:

—
обследование предметной области,
изучение ее информационной структуры;

—
выявление всех фрагментов, каждый из
которых характеризуется пользовательским
представлением, информационными
объектами, свя­зями между ними и
процессами;

·-
моделирование и интеграция всех
представлений.

Результат
данного этапа – концептуальная модель,
ин­вариантная к структуре Базы данных,
часто представляется в виде модели
«сущ­ность-связь».

Логическое
проектирование– преобразование
требований к данным в структуры данных.
Результат – СУБД-ориентированная
структура Базы данных и спецификации
прикладных программ. На этом этапе часто
мо­делируют Базы данных применительно
к различным СУБД и проводят сравнительный
анализ моделей.

Физическое
проектирование
– определение особенностей хранения
данных, методов доступа и т. д. Физическая
база данных нужна разработчикам
информационной сис­темы для разработки
кода, а проектировщикам – для проверки
их идей. Проектировщики и разработчики
могут работать как с одной и той же
схемой, так и с разными схемами. В процессе
разработки проекта, как правило, создается
несколько версий схемы.

Построение
логической и физиче­ской моделей
данных является основной частью
проектирования Базы данных.

Физическое проектирование БД

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

Построение физической модели сопряжено с решением во многом противоречивых задач:

1. задачи минимизации места хранения данных,
2. задачи достижения целостности, безопасности и максимальной производительности.

Вторая задача вступает в конфликт с первой, поскольку, например:

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

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

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

В мир плавных форм от точных прямоугольников

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

Мощь и объективность реляционных отношений — бесспорна, но разве динамика колонок и строк наносит ущерб их репутации? Таблица — это просто данные, которые могут иметь шапку (список колонок) или не иметь строк. Пусть таблица — это просто совокупность данных, не обязательно именованная.

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

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

Предметом работы станет не описание структуры базы данных, а динамика движения информации. Этапы работ распределятся на три центра тяжести:

• входной информационный поток;
• преобразования и движение информации внутри базы данных;
• выборка данных для использования.

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

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

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

Этапы или коллектив: баланс приоритетов

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

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

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

Никакая технология не развивается сама по себе, ее двигают вперед люди

Квалификация коллектива разработчиков имеет важное значение. Информационная модель базы данных — это не только каркас, но и информационные потоки

Что приоритетнее: красивая графика в представлении структуры базы данных или точное описание информационных потоков в динамике — вопрос не только поставленной задачи и области применения, но и мнение коллектива разработчиков в динамике.

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

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

Выполнить работу нужно сегодня, новая задача, современное оборудование, свежие технологии, …

Возможен обратный вариант. Есть Excel и Access и «обильные» данные в этих форматах с давних времен, когда еще был жив и здравствовал Windows for Workgoups. Частично остались данные dBase и Quattro. Сегодня эти слова уже забылись, но информация осталась, она востребована и нуждается в извлечении и формировании новых представлений.

2.4. Microsoft Access 2007

2.4.2. Создание базы данных (таблиц и связей между ними) в Access 2007

Рассмотрим этапы создания БД «Деканат» с помощью СУБД Access 2007. Сначала составляем модель «сущность – связь» для базы данных «Деканат». Этапы проектирования модели «сущность – связь» изложены в разделе «Создание БД. Этапы проектирования».

После создания модели запускаем приложение Access 2007. Открывается окно приложение Access 2007 на странице Приступая к работе с Microsoft Access 2007. В разделе Новая пустая база данных щелкаем на пиктограмме Новая база данных. В правой части окна появится информация об имени файла и указана директория для его хранения. По умолчанию имя файла — База данных1.accdb.

Изменить имя файла и путь к директории для хранения файла БД можно в окне «Файл новой базы данных» щелкнув на пиктограмме «Поиск расположения для размещения базы данных». Установив имя файла — Деканат_2007.accdb и требуемое имя директории в окне «Файл новой базы данных», надо щелкнуть на кнопке ОК, окно закроется.

Далее необходимо щелкнуть на кнопке Создать, чтобы создать пустую базу данных. При создании новой пустой базы данных окно приложения Access 2007 открывается на контекстной вкладке «Режим таблицы». В окне отображается новая пустая таблица с именем Таблица 1 в режиме таблица, представленная на Рис. 1.

Рис. 1.

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

Рис. 2.

Откроется окно Сохранение, в котором надо указать имя Группы студентов и нажать кнопку ОК.

Рис. 3.

Откроется таблица Группы студентов в режиме Конструктор

Рис. 4.

Создаем структуру таблицы Группы студентов. В первую строку колонки «Имя поля» вводим код группы студентов (КодГруппы) и нажимаем клавишу Enter. Курсор переместится в колонку Тип данных. Access по умолчанию назначает тип данных — Счетчик. Нажимаем клавишу Enter, при этом курсор переместится в колонку Описание, при необходимости вводим описание данных.

Первой строке таблицы (поле КодГруппы) Access по умолчанию назначает поле первичного ключа. Для первичного ключа в свойствах поля устанавливается значение Индексированного поля: Да (Совпадения не допускаются). Далее заполняем вторую строку (второе поле таблицы), Имя поля — Название, Тип данных — текстовый. Третья строка: Имя поля — Курс, Тип данных — числовой и четвертая строка Имя поля — Семестр, Тип данных — числовой. При этом для имени поля «Название» в разделе свойства поля необходимо установить размер поля — 6.

Рис. 5.

Затем создаем структуры остальных трех таблиц в соответствии с характеристиками таблиц-объектов Студенты, Дисциплины, Успеваемость. Обязательно соблюдайте указанную последовательность создания структуры таблиц.

Необходимо отметить, что в структуре таблицы «Студенты» для поля КодГруппы (вторичный ключ) установите значение Индексированного поля: Да (Совпадения допускаются) и тип данных — мастер подстановок. В структуре таблицы «Успеваемость» для поля КодСтуденты (вторичный ключ) и поля КодДисциплины (вторичный ключ) установите значение Индексированного поля: Да (Совпадения допускаются) и тип данных — мастер подстановок.

Структуры остальных таблиц: Студенты, Дисциплины, Успеваемость:

Рис. 6

Рис. 7

Рис. 8

После этого необходимо установить логические связи между всеми таблицами.

Далее >>> 2.4.3. Установка связей между таблицами в СУБД Access 2007

Варианты создания баз данных в Microsoft Access

Пустую базу данных можно создать в проводнике Windows, щелкнув правой кнопкой на пустом пространстве и выбрав «Создать… Базу данных Microsoft Access». Появится пустой файл (ему сразу же можно присвоить подходящее имя), который следует открыть двойным щелчком. Однако в современных версиях программы предусмотрены более эффективные способы выполнения этого действия.

Работа с шаблонами

Можно создать новую БД:

• из стандартного шаблона: несколько готовых шаблонов поставляются вместе с программой;
• из шаблона с сайта Office.com: там имеется обширная коллекция заготовок для баз данных различного назначения; их можно загружать по сети с помощью меню (вкладка «Создать»).

Рисунок 1. Варианты создания новой базы данных в MS Access. Автор24 — интернет-биржа студенческих работ

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

Шаблоны, как и пустые базы данных, можно редактировать: добавлять и изменять таблицы, формы и другие объекты.

Замечание 2

С сайта Office.com можно загружать не только целые шаблоны, но и так называемые «части приложения» — связанные между собой компоненты, например, таблица и построенная на ее основе форма.

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

Создание пустой базы данных

Для создания пустой БД следует на вкладке «Файл» выбрать пункт «Создать» и вариант «Пустая база данных», затем указать имя файла. Access создаст БД с незаполненной таблицей «Таблица1». Она сразу же будет открыта в режиме таблицы. Для добавления данных нужно просто вводить их, отложив оптимизацию структуры колонок. Процесс ввода данных похож на работу с листом Excel.

Замечание 3

Файл Blank.accdb в папке :\Program Files\Microsoft Office\Templates\1049\Access. используется как шаблон для всех новых локальных пустых баз данных. Все новые базы данных наследуют содержимое этого файла. Это отличный способ распространения содержимого по умолчанию.

Способы выделения файлов и папок

Для начала разберемся, зачем вообще выделять файлы?

На ум приходит только три основные причины: и информация!

Естественно, когда Вам нужно скопировать/переместить больше одного файла, то выделение просто необходимо. Ведь проще скопировать сразу всё, чем по отдельности.

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

Теперь ближе к делу!

Все способы я буду демонстрировать на примере вот этих папок:

Способ №1. Прямоугольное выделение мышкой

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

Выделяются все файлы, попавшие в эту область.

Способ №2. Выборочное выделение

Этот способ я считаю самым универсальным! Можно выделить что угодно и в любой последовательности. Например вот так

Для этого нужно зажать клавишу “Ctrl” (она расположена в левом нижнем углу клавиатуры) и щелкать мышкой по нужным файлам.

Если Вы случайно выделили не тот файл, то просто щелкните по нему еще раз и выделение снимется, естественно клавиша “Ctrl” должно быть зажата (иначе выделение пропадет со всех файлов).

В промежутках между нажатиями, “Ctrl” можно отпускать, т.е. выделив несколько файлов, Вы можете отпустить “Ctrl” и пролистать окно (посмотреть какие еще файлы в нем есть), затем снова зажать “Ctrl” и продолжить выделение.

Способ №3. Последовательное выделение

Выделение происходит между папками/файлами.

Сначала левым щелчком мыши нужно выделить начальную папку, зажать клавишу “Shift” , щелкнуть левой кнопкой мышки по конечной папке.

При этом выделяются заданные папки и все что между ними.

Вот такие простые способы, могут не раз облегчить Вам жизнь

Так же их можно комбинировать, в зависимости от ситуации.

Например, вот такое выделение:

Первые три строчки я выделил с помощью прямоугольного выделения, затем зажал клавишу “Ctrl” и выделил еще несколько папок вразброс.

Можно сделать и по-другому: всё выделить прямоугольником, зажать клавишу “Ctrl” и убрать ненужные файлы.

Полное выделение

Иногда нам приходится выделять всё, что находится в окне. Опять же сделать это можно по-разному.

1. С помощью любого выше перечисленного способа.

2. В окне, на панели инструментов нажать кнопку “Упорядочить” , затем выбрать “Выделить всё” .

3. Выделить первый файл в окне и нажать комбинацию клавиш “Shift” + “End” (зажать кнопку “Shift” и не отпуская её, нажать “End” ).

4. Выделить последний файл в окне и нажать комбинацию клавиш “Shift” + “Home” .

Расположение клавиш (для увеличения нажмите на изображение)

Ну вот вроде бы и всё, что я хотел сказать. До встречи на следующих уроках!

Инфологическое проектирование

Идентификация сущностей составляет смысловую основу инфологического проектирования. Сущность здесь – это такой объект (абстрактный или конкретный), информация о котором будет накапливаться в системе. В инфологической модели предметной области в понятных пользователю терминах, которые не зависят от конкретной реализации БД, описывается структура и динамические свойства предметной области. Но термины, при этом берутся в типовых масштабах. То есть, описание выражается не через отдельные объекты предметной области и их взаимосвязи, а через:

• описание типов объектов,
• ограничения целостности, связанные с описанным типом,
• процессы, приводящие к эволюции предметной области – переходу её в другое состояние.

Инфологическую модель можно создавать с помощью нескольких методов и подходов:

1. Функциональный подход отталкивается от поставленных задач. Функциональным он называется, потому что применяется, если известны функции и задачи лиц, которые с помощью проектируемой базы данных будут обслуживать свои информационные потребности.
2. Предметный подход во главу угла ставит сведения об информации, которая будет содержаться в базе данных, при том, что структура запросов может не быть определена. В этом случае в исследованиях предметной области ориентируются на её максимально адекватное отображение в базе данных в контексте полного спектра предполагаемых информационных запросов.
3. Комплексный подход по методу «сущность-связь» объединяет достоинства двух предыдущих. Метод сводится к разделению всей предметной области на локальные части, которые моделируются по отдельности, а затем вновь объединяются в цельную область.

Поскольку использование метода «сущность-связь» является комбинированным способом проектирования на данном этапе, он чаще других становится приоритетным.

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

Зависимость сущностей отражается в разделении их на сильные (базовые, родительские) и слабые (дочерние). Сильная сущность (например, читатель в библиотеке) может существовать в БД сама по себе, а слабая сущность (например, абонемент этого читателя) «привязывается» к сильной и отдельно не существует.

Для каждой отдельной сущности выбираются атрибуты (набор свойств), которые в зависимости от критерия могут быть:

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

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

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