Topics Covered:
=================================================
The Three-Level ANSI-SPARC Architecture
Database Languages
Data Models and Conceptual Modeling
Topics included:
=================================================
Assembly Language
CISC Instruction Sets
Characteristics of RISC
RISC and CISC Styles
Encoding of Machine Instructions
CS4443 - Modern Programming Language - I Lecture (2)Dilawar Khan
Topic Covered:
================================================
Basic Data Types and their Mapping to CTS
Variables, Constants, and Operators
Working with Flow Control and Conditional Statements
Type Conversion, String Manipulation and Complex Variable Types
Arrays in C#
foreach loop
Topics included:
===============================================
The different types of computers
The basic structure of a computer and its operation
Machine instructions and their execution
Integer, floating-point, and character representations
Addition and subtraction of binary numbers
Basic performance issues in computer systems
A brief history of computer development
Topics included:
=================================================
Assembly Language
CISC Instruction Sets
Characteristics of RISC
RISC and CISC Styles
Encoding of Machine Instructions
CS4443 - Modern Programming Language - I Lecture (2)Dilawar Khan
Topic Covered:
================================================
Basic Data Types and their Mapping to CTS
Variables, Constants, and Operators
Working with Flow Control and Conditional Statements
Type Conversion, String Manipulation and Complex Variable Types
Arrays in C#
foreach loop
Topics included:
===============================================
The different types of computers
The basic structure of a computer and its operation
Machine instructions and their execution
Integer, floating-point, and character representations
Addition and subtraction of binary numbers
Basic performance issues in computer systems
A brief history of computer development
The presentation includes brief insight of mostly all important OOPs concepts including Exception Handling, File Handling, Dynamic Memory Allocation, Storage Classes, Namespaces, and Generic Programming.
Edhole School provides best Information about Schools in India, Delhi, Noida, Gurgaon. Here you will get about the school, contact, career, etc. Edhole Provides best study material for school students.
Should I move my database to the cloud?James Serra
So you have been running on-prem SQL Server for a while now. Maybe you have taken the step to move it from bare metal to a VM, and have seen some nice benefits. Ready to see a TON more benefits? If you said “YES!”, then this is the session for you as I will go over the many benefits gained by moving your on-prem SQL Server to an Azure VM (IaaS). Then I will really blow your mind by showing you even more benefits by moving to Azure SQL Database (PaaS/DBaaS). And for those of you with a large data warehouse, I also got you covered with Azure SQL Data Warehouse. Along the way I will talk about the many hybrid approaches so you can take a gradual approve to moving to the cloud. If you are interested in cost savings, additional features, ease of use, quick scaling, improved reliability and ending the days of upgrading hardware, this is the session for you!
The presentation includes brief insight of mostly all important OOPs concepts including Exception Handling, File Handling, Dynamic Memory Allocation, Storage Classes, Namespaces, and Generic Programming.
Edhole School provides best Information about Schools in India, Delhi, Noida, Gurgaon. Here you will get about the school, contact, career, etc. Edhole Provides best study material for school students.
Should I move my database to the cloud?James Serra
So you have been running on-prem SQL Server for a while now. Maybe you have taken the step to move it from bare metal to a VM, and have seen some nice benefits. Ready to see a TON more benefits? If you said “YES!”, then this is the session for you as I will go over the many benefits gained by moving your on-prem SQL Server to an Azure VM (IaaS). Then I will really blow your mind by showing you even more benefits by moving to Azure SQL Database (PaaS/DBaaS). And for those of you with a large data warehouse, I also got you covered with Azure SQL Data Warehouse. Along the way I will talk about the many hybrid approaches so you can take a gradual approve to moving to the cloud. If you are interested in cost savings, additional features, ease of use, quick scaling, improved reliability and ending the days of upgrading hardware, this is the session for you!
As more businesses realised that data, in all forms and sizes, is critical to making the best possible decisions, we see the continued growth of systems that support massive volume of non-relational or unstructured forms of data. Nothing shows the picture more starkly than the Gartner Magic quadrant for operational database management systems, which assumes that, by 2017, all leading operational DBMSs will offer multiple data models, relational and NoSQL, in a single DBMS platform. Having a single data platform for managing both well-structured data and NoSQL data is beneficial to users; this approach reduces significantly integration, migration, development, maintenance, and operational issues. Therefore, a challenging research work is how to develop efficient consolidated single data management platform covering both relational data and NoSQL to reduce integration issues, simplify operations, and eliminate migration issues.
In this tutorial, we review the previous work on multi-model data management and provide the insights on the research challenges and directions for future work.
Papers and more materials on this tutorial can be found at: http://udbms.cs.helsinki.fi/?tutorials
How to generate customized java 8 code from your databaseSpeedment, Inc.
Did you know that database classes, that require many lines of Java and SQL code, may be replaced with a single line of Java 8 code? In this tutorial session you will learn how to use standard Java 8 Streams as an alternative to traditional Object Relational Mappers (ORM). We will use the open-source tool Speedment to show how development speed can be increased and how the application code can be more concise and run faster.
Functional Database Strategies at Scala BayJason Swartz
As developers using a functional programming language, we embrace immutable collections and pure functions in our code. However, we often have separate rules for how we work with our persistent collections in databases. In this talk we'll look at why & how to take a more functional approach to persistence with databases, from managing the connections, using immutable table rows, and considering event-source persistence
Topics Covered:
=================================================
Business Plan and Business Model
Ingredients of a Business Model
Major B2C Business Model
Topics Covered
================================================================
Computer and Computer Network
Introduction to Internet, Web & Their Growth
What is E-commerce?
Define E-commerce and Describe How it Differs From E-business
Why Study E-commerce?
Unique Features of E-commerce
Major Types and Dimensions of E-commerce
Overview, Database System vs File System, Database System Concept and
Architecture, Data Model Schema and Instances, Data Independence and Database Language and
Interfaces, Data Definitions Language, DML, Overall Database Structure. Data Modeling Using the
Entity Relationship Model: ER Model Concepts, Notation for ER Diagram, Mapping Constraints,
Keys, Concepts of Super Key, Candidate Key, Primary Key, Generalization, Aggregation,
Reduction of an ER Diagrams to Tables, Extended ER Model, Relationship of Higher Degree.
Read| The latest issue of The Challenger is here! We are thrilled to announce that our school paper has qualified for the NATIONAL SCHOOLS PRESS CONFERENCE (NSPC) 2024. Thank you for your unwavering support and trust. Dive into the stories that made us stand out!
How to Split Bills in the Odoo 17 POS ModuleCeline George
Bills have a main role in point of sale procedure. It will help to track sales, handling payments and giving receipts to customers. Bill splitting also has an important role in POS. For example, If some friends come together for dinner and if they want to divide the bill then it is possible by POS bill splitting. This slide will show how to split bills in odoo 17 POS.
The Roman Empire A Historical Colossus.pdfkaushalkr1407
The Roman Empire, a vast and enduring power, stands as one of history's most remarkable civilizations, leaving an indelible imprint on the world. It emerged from the Roman Republic, transitioning into an imperial powerhouse under the leadership of Augustus Caesar in 27 BCE. This transformation marked the beginning of an era defined by unprecedented territorial expansion, architectural marvels, and profound cultural influence.
The empire's roots lie in the city of Rome, founded, according to legend, by Romulus in 753 BCE. Over centuries, Rome evolved from a small settlement to a formidable republic, characterized by a complex political system with elected officials and checks on power. However, internal strife, class conflicts, and military ambitions paved the way for the end of the Republic. Julius Caesar’s dictatorship and subsequent assassination in 44 BCE created a power vacuum, leading to a civil war. Octavian, later Augustus, emerged victorious, heralding the Roman Empire’s birth.
Under Augustus, the empire experienced the Pax Romana, a 200-year period of relative peace and stability. Augustus reformed the military, established efficient administrative systems, and initiated grand construction projects. The empire's borders expanded, encompassing territories from Britain to Egypt and from Spain to the Euphrates. Roman legions, renowned for their discipline and engineering prowess, secured and maintained these vast territories, building roads, fortifications, and cities that facilitated control and integration.
The Roman Empire’s society was hierarchical, with a rigid class system. At the top were the patricians, wealthy elites who held significant political power. Below them were the plebeians, free citizens with limited political influence, and the vast numbers of slaves who formed the backbone of the economy. The family unit was central, governed by the paterfamilias, the male head who held absolute authority.
Culturally, the Romans were eclectic, absorbing and adapting elements from the civilizations they encountered, particularly the Greeks. Roman art, literature, and philosophy reflected this synthesis, creating a rich cultural tapestry. Latin, the Roman language, became the lingua franca of the Western world, influencing numerous modern languages.
Roman architecture and engineering achievements were monumental. They perfected the arch, vault, and dome, constructing enduring structures like the Colosseum, Pantheon, and aqueducts. These engineering marvels not only showcased Roman ingenuity but also served practical purposes, from public entertainment to water supply.
We all have good and bad thoughts from time to time and situation to situation. We are bombarded daily with spiraling thoughts(both negative and positive) creating all-consuming feel , making us difficult to manage with associated suffering. Good thoughts are like our Mob Signal (Positive thought) amidst noise(negative thought) in the atmosphere. Negative thoughts like noise outweigh positive thoughts. These thoughts often create unwanted confusion, trouble, stress and frustration in our mind as well as chaos in our physical world. Negative thoughts are also known as “distorted thinking”.
Ethnobotany and Ethnopharmacology:
Ethnobotany in herbal drug evaluation,
Impact of Ethnobotany in traditional medicine,
New development in herbals,
Bio-prospecting tools for drug discovery,
Role of Ethnopharmacology in drug evaluation,
Reverse Pharmacology.
Welcome to TechSoup New Member Orientation and Q&A (May 2024).pdfTechSoup
In this webinar you will learn how your organization can access TechSoup's wide variety of product discount and donation programs. From hardware to software, we'll give you a tour of the tools available to help your nonprofit with productivity, collaboration, financial management, donor tracking, security, and more.
Instructions for Submissions thorugh G- Classroom.pptxJheel Barad
This presentation provides a briefing on how to upload submissions and documents in Google Classroom. It was prepared as part of an orientation for new Sainik School in-service teacher trainees. As a training officer, my goal is to ensure that you are comfortable and proficient with this essential tool for managing assignments and fostering student engagement.
Thesis Statement for students diagnonsed withADHD.ppt
CS3270 - DATABASE SYSTEM - Lecture (2)
1. CS3270
DATABASE – I
Mr. Dilawar
Lecturer,
Computer Science Faculty,
Bakhtar University
Kabul, Afghanistan.
2. Previous Lecture Outline
• Introduction
• Traditional File-Based Systems
• Database Approach
• Roles in the Database Environment
• History of DBMS
• Advantages and Disadvantages of DBMSs
4. Chapter Outline
• The Three-Level ANSI-SPARC Architecture
• Database Languages
• Data Models and Conceptual Modeling
• Functions of DBMS
• Components of DBMS
• Multi-User DBMS Architecture
5. Lecture Outline
• The Three-Level ANSI-SPARC Architecture
• Database Languages
• Data Models and Conceptual Modeling
6. The Three-Level ANSI-SPARC Architecture
• Identifies three levels of abstraction.
• Three distinct levels at which data items can be
described.
• The three-level architecture comprising an
external, a conceptual, and an internal level as
shown in the figure.
• The way users observes the data is called external
level.
• The way DBMS and OS observes data is called the
internal level.
• Where the data is actually stored using the data
structures and file organizations.
• Conceptual level provides both the mapping and the
desired independence between external and internal
levels.
7. The Three-Level ANSI-SPARC Architecture
• The objective of three-level architecture is to separate each user’s view of the
database from the way the database is physically represented.
• There are several reasons why this is desirable.
• All users should be able to access same data but have a different customized view.
• A user’s view is safe to changes made in other views.
• Users should not need to know physical database storage details.
• DBA should be able to change database storage structures without affecting the users’ views.
• Internal structure of database should be unaffected by changes to physical aspects of storage
such as changeover to a new storage device.
• DBA should be able to change conceptual structure of database without affecting all users.
8. The Three-Level ANSI-SPARC Architecture
• External Level
• The users’ view of the database. It Describes that part of database that is
relevant to a each user.
• The external level consists of a number of different external views of the
database.
• Each user has a view of the ‘real world’ represented in a form that is familiar for that
user.
• Different views may have different representation of same data (e.g. different
date formats, age derived from DOB etc.).
9. The Three-Level ANSI-SPARC Architecture
• Conceptual Level
• Community view of the database. It describes what data is stored in database
and the relationships among the data.
• It is a complete view of the data requirements of the organization that is
independent of any storage considerations.
• It represents
• All entities, their attributes, and their relationships.
• The constraints on the data.
• Semantic information about the data.
• Security and integrity information.
10. The Three-Level ANSI-SPARC Architecture
• Internal Level
• Physical representation of the database on the computer. This level describes
how the data is stored in the database.
• It covers the physical implementation of the database to achieve optimal
runtime performance and storage space utilization.
• It covers data structures and file organizations used to store data on storage
devices.
• Interfaces with the operating system access methods to place the data on the
storage devices, build the indexes, retrieve the data, and so on.
12. The Three-Level ANSI-SPARC Architecture
Schemas
• The overall description of the database is called the database schema.
• There are three schemas as per three-level architecture.
• External Schema
• Conceptual Schema
• Internal Schema
13. The Three-Level ANSI-SPARC Architecture
• External Schemas
• Also called subschemas.
• Corresponds to different views of data.
• Multiple schemas per database.
• Conceptual Schema
• Describes all the entities, attributes, and relationships together with integrity
constraints
• Only one schema per database.
14. The Three-Level ANSI-SPARC Architecture
• Internal Schema
• A complete description of the internal model, containing the definitions of
stored records, the methods of representation, the data fields, and the
indexes and storage structures used.
• Only one schema per database.
15. The Three-Level ANSI-SPARC Architecture
Mapping
• The DBMS is responsible for mapping between these three types of
schema:
• The DBMS must check that each external schema is derivable from the
conceptual schema, and it must use the information in the conceptual
schema to map between each external schema and the internal schema.
• Types of mappings
• Conceptual/Internal mapping
• External/Conceptual mapping
16. The Three-Level ANSI-SPARC Architecture
• Conceptual/Internal Mapping
• Enables the DBMS to find the actual record or combination of records in
physical storage that establishes a logical record in the conceptual schema,
together with any constraints to be enforced on the operations for that logical
record.
• It also allows any differences in entity names, attribute names, attribute
order, data types, and so on, to be resolved.
• External/Conceptual Mapping
• Enables the DBMS to map names in the user’s view on to the relevant part of
the conceptual schema.
18. The Three-Level ANSI-SPARC Architecture
• Database Schema
• Description of database (also called intension).
• Specified during design phase.
• Remain almost static.
• Database Instance
• Data in the database at any particular point in time.
• Dynamic (changes with the time).
• Also called an extension (or state) of database.
19. The Three-Level ANSI-SPARC Architecture
Data Independence
• A major objective for the three-level architecture is to provide data-
independence.
• Upper levels are unaffected by changes to lower levels.
• There are two kinds of data-independence:
• Logical Data Independence
• Physical Data Independence
20. The Three-Level ANSI-SPARC Architecture
• Logical Data Independence
• Refers to protection of external schemas to changes in conceptual schema.
• Conceptual schema changes (e.g. addition/removal of entities).
• Should not require changes to external schema or rewrites of application
programs.
21. The Three-Level ANSI-SPARC Architecture
• Physical Data Independence
• Refers to immunity of conceptual schema to changes in the internal schema.
• Internal schema changes (e.g. using different file organizations, storage
structures, storage devices etc.).
• Should not require change to conceptual or external schemas.
23. Database Languages
• Data sublanguage consist of two parts:
• DDL (Data Definition Language)
• DML (Data Manipulation Language)
• Data sublanguage
• Does not include constructs for all computing needs such as iterations or
conditional statements, which are provided by HLL.
• Many DBMSs provide embedding the sublanguage in a high level
programming language e.g. C, C++, Java etc.
• In this case , these high level languages are called host languages.
24. Database Languages
• Data Definition Language
• Allows the DBA or user to describe and name entities, attributes, and
relationships required for the application
• Plus any associated integrity and security constraints.
• The result is a set of tables stored in special files collectively called the System
catalog (data dictionary, data directory).
• Metadata (data about data, data description, data definitions).
25. Database Languages
• Data Manipulation Language
• Provides basic data manipulation operations on data held in the database.
• Procedural DML
• Non-Procedural DML
26. Database Languages
• Data Manipulation Language
• Procedural DML allows user to tell system exactly how to manipulate data.
• Operate on records individually.
• Typically, embedded in a high level language.
• More work is done by user (programmer).
• Network or hierarchical DMLs.
27. Database Languages
• Data Manipulation Language
• Non-Procedural DML Allows user to state what data is needed rather than
how it is to be retrieved
• Operate on set of records.
• Relational DBMS include e.g. SQL, QBE etc.
• Easy to understand and learn than procedural DML.
• More work is done by DBMS than user.
• Also called declarative languages.
28. Database Languages
• Fourth Generation Languages
• No clear agreement
• Forms generators
• Report generators
• Graphics generators
• Application generators
• Examples : SQL and QBE
29. Data Models
• A set of concepts to describe the structure of a database, the
operation for manipulating these structures, and certain constraints.
• Represents the organization itself.
• To represent data in an understandable way.
• Should provide the basic concepts and notations that will allow
database designers and end-users to accurately communicate their
understanding of the organizational data.
30. Data Models
• A data model comprises:
• A structural part
• Consisting of a set of rules according to which
databases can be constructed.
• A manipulative part
• Operations that are allowed on the data.
• Possibly a set of integrity rules
• Which ensures that the data is accurate.
Structure Constraints
Operations
Data Model describes
31. Data Models
• ANSI-SPARC architecture related models
• External data model (Universe of Discourse)
• Represent each user’s view of the organization.
• Conceptual data model (DBMS independent)
• Represent the community view that is DBMS independent.
• Internal data model
• Represent the conceptual schema in such a way that it can be understood by the DBMS.
32. Data Models
• Categories of data models include:
• Object-based
• Entity-Relationship
• Semantic
• Functional
• Object-Oriented
• Record-based
• Relational Data Model
• Network Data Model
• Hierarchical Data Model
• Physical
Relational Systems adopt a declarative
approach to database processing (that is,
they specify what data is to be retrieved).
Network and hierarchical systems adopt a
navigational approach (that is, they
specify how the data is to be retrieved).
36. Conceptual Modeling
• Conceptual modeling is process of developing a model of information
use in an enterprise that is independent of implementation details.
• Should be complete and accurate representation of an organization’s data
requirements.
• Conceptual schema is the core of a system supporting all user views.
• Conceptual vs. logical data model
37. Summery
• The Three-Level ANSI-SPARC Architecture
• Database Languages
• Data Models and Conceptual Modeling
An early proposal for a standard terminology and general architecture for database systems was produced in 1971 by the DBTG (Data Base Task Group) appointed by the Conference on Data Systems and Languages (CODASYL, 1971).
The DBTG recognized the need for a two-level approach with a system view called the schema and user views called subschemas.
Entities, attributes and relationships that are desirable to the user.
The conceptual level supports each external view, in that any data available to a user must be contained in, or derivable from, the conceptual level. However, this level must not contain any storage-dependent details.
Description of an entity should contain only datatypes of attributes and their lengths but not any storage consideration such as the number of bytes occupied.
Below the internal level there is a physical level that may be managed by the operating system under the direction of the DBMS.
The physical level below the DBMS consists of items only the operating system knows, such as exactly how the sequencing is implemented and whether the fields of internal records are stored as contiguous bytes on the disk.
Mapping – charting
Clearly, the users for whom the changes have been made need to be aware of them, but what is important is that other users should not be.
Unambiguous – unmistakable
We mentioned earlier that a schema is written using a data definition language. In fact, it is written in the data definition language of a particular DBMS. Unfortunately, this type of language is too low level to describe the data requirements of an organization in a way that is readily understandable by a variety of users. What we require is a higher-level description of the schema: that is, a data model.
The purpose of a data model is to represent data and to make the data understandable. If it does this, then it can be easily used to design a database.
Provide concepts that are close to the way many users identify data.
A logical data model describes the data in as much detail as possible that can be implemented in a specified DBMS.
Provide concepts that describes details of how data is stored in the computer.
Physical data model represents how the model will be built in the database.
Object-based, record-based – conceptual and external levels.
Physical model describes data at the internal level.
Object-based data models use concepts such as entities, attributes, and relationships.
The object-oriented data model extends the definition of an entity to include not only the attributes that describe the state of the object but also the actions that are associated with the object, that is, its behavior. The object is said to encapsulate both state and behavior.
In a record-based model, the database consists of a number of fixed-format records possibly of differing types. Each record type defines a fixed number of fields, each typically of a fixed length.
Physical data models describe how data is stored in the computer, representing information such as record structures, record orderings, and access paths. There are not as many physical data models as logical data models, the most common ones being the unifying model and the frame memory.
The relational data model is based on the concept of mathematical relations. In the relational model, data and relationships are represented as tables, each of which has a number of columns with a unique name.
In the network model, data is represented as collections of records, and relationships are represented by sets. Compared with the relational model, relationships are explicitly modeled by the sets, which become pointers in the implementation. The records are organized as generalized graph structures with records appearing as nodes (also called segments) and sets as edges in the graph. Figure 2.5 illustrates an instance of a network schema for the same data set presented in Figure 2.4. The most popular network DBMS is
Computer Associates’ IDMS/ R. We discuss the network data model in more detail on the Web site for this book (see Preface for the URL).
The hierarchical model is a restricted type of network model. Again, data is represented as collections of records and relationships are represented by sets. However, the hierarchical model allows a node to have only one parent. A hierarchical model can be represented as a tree graph, with records appearing as nodes(also called segments) and sets as edges.
The conceptual model is independent of all implementation details, whereas the logical model assumes knowledge of the underlying data model of the target DBMS.
Provide concepts that are close to the way many users identify data.
A logical data model describes the data in as much detail as possible that can be implemented in a specified DBMS.