
- •Вопрос 1
- •Вопрос 2
- •Вопрос 3
- •Вопрос 13
- •Архиваторы
- •Программы обслуживания жестких дисков
- •Вопрос 12
- •Вопрос 14
- •Вопрос 15
- •Вопрос 21 основные понятия
- •33.Данные. Основные понятия баз данных:объект,поле,домен,атрибут,ключ
- •33.Данные. Основные понятия баз данных:объект,поле,домен,атрибут,ключ
- •34.Модель «сущность – связь»
- •35.Иерархическая модель
- •36.Сетевая модель данных.
- •38.Операции реляционной алгебры: булевы операции
- •40.Операции реляционной алгебры: выборка, проекция, соединение, деление.
- •41.Понятие функциональной, полной функциональной и транзитивной зависимостей.Примеры.
- •42.Нормализация данных.Нормальные формы отношений
- •43. Обеспечение непротиворечивости и целостности в отношениях.
- •44.Типы взаимосвязей в модели: «один-к-одному», «один-ко-многим», «многие-ко-многим»
- •45.Основные принципы и этапы проектирования бд.
- •46.Жизненный цикл бд
- •58.Трехуровневая организация бд: внешняя, концептуальная, внутренняя модели
- •49.Диаграммы потоков данных. Нотация. Пример.
- •51. Современные средства быстрой разработки приложений(rad-средства). Основные функции, применение, достоинства и недостатки метода.
- •52.Базовые понятия субд. Основные функции субд.
- •53.Классификация и типы субд.
- •54.Сравнительная характеристика субд.
- •55.Sql: общая характеристика, основные понятия.
- •56.Sql: простейшие запросы.Примеры.
- •57. Механизм транзакций. Основные свойства.
- •58. Транзакции. Блокировки.
- •59.Транзакция. Временные отметки.
- •60. Защита баз данных. Обеспечение целостности данных.
58.Трехуровневая организация бд: внешняя, концептуальная, внутренняя модели
Наиболее удобной организацией СУБД оказалась трехуровневая организация БД 1. внешняя модель – определяет точки зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые ему нужны. Например система распределения работ использует сведения о квалификации сотрудника. Ее не интересует его личные данные (адрес, телефон), которую использует подсистема отдельных кадров. 2. концептуальная модель – объединяет данные, используемые всеми приложениями, работающие с БД. Фактически этот уровень отражает обобщенную модель конкретной области. 3. внутренняя модель – собственно данные в виде файлов или страниц структур, расположенные на внешнем носителе информации.
48.ER- моделирование: сущность, атрибуты, связь. Логическая и физическая структура БД
Модель сущность-связь (ER-модель) (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области.
ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.
Сущность изображается в виде прямоугольника, содержащем её имя, выражаемое существительным.[5]Имя сущности должно быть уникальным в рамках одной модели. При этом, имя сущности — это имя типа, а не конкретного экземпляра данного типа. Экземпляром сущности называется конкретный представитель данной сущности.
Связь изображается линией, которая связывает две сущности, участвующие в отношении. Степень конца связи указывается графически, множественность связи изображается в виде «вилки» на конце связи. Модальность связи так же изображается графически — необязательность связи помечается кружком на конце связи. Именование обычно выражается одним глаголом в изъявительном наклонении настоящего времени: «Имеет», «Принадлежит» и т. д.; или глаголом с поясняющими словами: «Включает в себя», и т.п. Наименование может быть одно для всей связи или два для каждого из концов связи. Во втором случае, название левого конца связи указывается над линией связи, а правого – под линией. Каждое из названий располагаются рядом с сущностью, к которой оно относится. Атрибуты сущности записываются внутри прямоугольника, изображающего сущность и выражаются существительным в единственном числе (возможно, с уточняющими словами). Среди атрибутов выделяется ключ сущности — неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности.
49.Диаграммы потоков данных. Нотация. Пример.
ДПД - это график, на котором показано движение значений данных от их источников через преобразующие их процессы к их потребителям в других объектах.ДПД содержит процессы, которые преобразуют данные, потоки данных, которые переносят данные, активные объекты, которые производят и потребляют данные, и хранилища данных, которые пассивно хранят данные.Процесс преобразует значения данных. Процессы самого нижнего уровня представляют собой функции без побочных эффектов (примерами таких функций являются вычисление суммы двух чисел, вычисление комиссионного сбора за выполнение проводки с помощью банковской карточки и т.п.). Весь граф потока данных тоже представляет собой процесс (высокого уровня). Процесс может иметь побочные эффекты, если он содержит нефункциональные компоненты, такие как хранилища данных или внешние объекты.Нота́ция (от лат. notatio — записывание, обозначение) — система условных обозначений, принятая в какой-либо области знаний или деятельности.Нотация включает множество символов используемых для представления понятий и их взаимоотношений, составляющее алфавит нотации, а также правила их применения.
50.Современные средства быстрой разработки приложений (RAD-средства). Краткая характеристика, примеры. RAD (от англ.rapid application development— быстрая разработка приложений)— концепция создания средств разработки программных продуктов,уделяющая особое внимание быстроте и удобству программирования,созданию технологического процесса,позволяющего программисту максимально быстро создавать компьютерные программы.С конца XXвека RAD получила широкое распространение и одобрение.Концепцию RADтакже часто связывают с концепцией визуального программирования.
Основные принципы RAD:1)Инструментарий должен быть нацелен на минимизацию времени разработки. 2)Создание прототипа для уточнения требований заказчика. 3)Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком. 4)Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию. 5)Команда разработчиков должна тесно сотрудничать, каждый участник должен быть готов выполнять несколько обязанностей. 6)Управление проектом должно минимизировать длительность цикла разработки.